Aminet 15

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 15 / Aminet 15 - Nov 1996.iso / Aminet / comm / fido / fnews3.lzh / fido306.nws < prev next >

Wrap

Text File | 1986-02-09 | 54KB | 1,387 lines

Volume 3, Number 6 10 February 1986 +----------------------------------------------------------+ | _ | | / \ | | - Fidonews - /|oo \ | | (_| /_) | | Fido and FidoNet _`@/_ \ _ | | Users Group | | \ \\ | | Newsletter | (*) | \ )) | | ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +----------------------------------------------------------+ Editor in Chief: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Fidonews is published weekly by SEAdog Leader, node 1/1. You are encouraged to submit articles for publication in Fidonews. Article submission standards are contained in the file FIDONEWS.DOC, available from node 1/1. Disclaimer or don't-blame-us: The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. Table of Contents 1. EDITORIAL 110 Baud and More History 2. ARTICLES Why Not to Use ANSI.SYS Looking for Old Talkies Confessions of a Fido Tyro A Suggestion For a New File Transfer Protocol A solution for using the new O(utside) command in FIDO 3. COLUMNS You Can dTUNE A Program But You Can't dTUNE a Fish Notes from Abroad 4. WANTED S.I.G administrators for Financial TeleShare. 5. FOR SALE Entertainment Software for your PC! 6. NOTICES The Interrupt Stack ============================================================ EDITORIAL ============================================================ Josh Gordon, 125/93 110 Baud and More History Boy do I remember 110 baud! I guess I am about the same generation as the Editor; let me elaborate a bit further on the setup I had in my first days with a microcomputer. At the time, I was a newly appointed Graduate Teaching Fellow in C.S. at the U. of Oregon. There was no office for me, so they stuck me in the room with the mini and microcomputers; a brier patch! Fun stuff. The newest acquisition was a remarkably well-stuffed IMSAI 8080, with (to stir up some nostalgia!) a Cromemco Dazzler, a TDL Z80 card, a Cyclops CCD camera (also by Cromemco, I seem to recall), an IMSAI VDM, a whopping 64K of RAM, and some or another serial card. Also resident: a trusty old Teletype. No disk drive, of course; as I was leaving, a Processor Tech disk drive was just being received. So: To use the IMSAI effectively, I had it down to this sequence: First I would key in a small boot program to the front panel. (I miss front panels! On the IMSAI, you could put the colored keys in whatever order you wanted; either RRRR BBBB RRRR BBBB if you were a HEX man, or if you were an OCTAL buff, R BBB RRR BBB RRR BBB.) This program was an absolute paper tape loader. I would then load in a more sophisticated hex checksum loader on paper tape. Now comes the fun part. In the same building lived a nice PDP-10. In the room with the micro were several serial ports. So, I would call up the PDP-10 operator, and say, "Hey John! Please connect line 39 at 19200". He would blanch a bit: 19200 was only used for this purpose, and put a somewhat disproportionate load on the Ten. Once it was hooked up, I had two things: either a remarkably fast PDP-10 terminal, the only one around, or an IMSAI 8080 with one hell of a peripheral (the 10). We actually got some pretty sophisticated stuff going, rudimentary image processing with the Cyclops, nice games with the Dazzler, that sort of thing. We had much more memory than any of our friends with micros; and the huge capacity of the 10, in comparison, gave us quite a nifty setup. As a result of my experience in that lab, and by virtue of the fact that an SF bookstore in Eugene was owned by the soon-to-be-ex-wife of a somewhat high muckamuck at IMSAI, my first job out of college was replacing a certain Rob Barnaby when he left IMSAI to work on an odd little program at that time NED, which evolved into WordStar. But the story of IMSAI is for another time, assuming someone is interested. ------------------------------------------------------------ Fidonews Page 2 10 Feb 1986 ============================================================ ARTICLES ============================================================ WHY NOT TO USE ANSI.SYS by Richard Ellis (Fido 102/509) This may sound heretical but if there's one thing I can't stand, it's a PC with ANSI.SYS installed. I have had this feeling since IBM first introduced it with DOS 2.0. Why must people feel that having something blessed by the American National Standards Institute makes it good and wonderful? The first problem is the memory ANSI.SYS takes. It takes it permanently; not just until you reboot. You have to edit the CONFIG.SYS file and reboot to recover the memory. The second problem is related to the first. You can't turn ANSI.SYS off! There is no way a program can say "Leave me alone, I'll do it myself!" I have been working on an energy conservation analysis system for over two and a half years. It does lots of screen manipulation. It doesn't work quite right if ANSI.SYS is installed. I use no ESC sequences at all but ANSI.SYS still interferes. The problems are subtle but they are there and they are problems. Finally, let's pretend we can live with the first two problems. The ANSI CRT standard has received much criticism due to its wordiness. To put it bluntly, it's SLOW! I don't think ANSI.SYS would be so bad if it could be turned on and off as needed by programs. I see no need to have it sitting around all the time taking memory when it's not needed or wanted. This would solve the interference problem and anyone that didn't mind their software running slow could use it. In conclusion I would like to plead to all software authors to not use ANSI.SYS. ------------------------------------------------------------ Fidonews Page 3 10 Feb 1986 Looking for Old Talkies It occured to me that a LOT of radio stations are switching from commercial two way gear to cellular mobile phones. Makes sense, faster, better quality, easier to put on the air, less maintenance. And I know that right now, anyway, used two-way gear is a drag on the market. Well, if your station is making the switch and you'd like to get rid of the old walkie-talkies and get a nice tax deduction, consider giving them to the American Council of the Blind. Every year we have to rent them for our annual convention at rip-off prices, but we just don't have the free cash right now to buy our own. Our annual convention has grown to the point where we have to have 'em just to keep functioning. Going to look for someone, or sticking a message up on a cork board just doesn't work when you are dealing with a meeting of 3,000 people, 95% of them blind. Plus our next convention, in Knoxville, Tennessee, in July, will be spread out between two major hotels! We are interested in most any kind of used commercial two- way gear, VHF or UHF. We also would be interested in chargers, batteries, cases, spare rubber duckies, etcetera. Just send Fidomail to Vernon Henley, Fido 147/1 and I will get right back to about your donation. Also, be watching down in this direction for a burst of interest in Fido from blind users. Our monthly magazine, the Braille Forum, will soon carry an article about Fido, and there are several other projects in the works. If you or someone you know would like a free subscription, just drop me a line at the same address. You need not be blind to receive the magazine. Please specify large print, cassette or Braille (the cassette requires a special type player that usually only a blind person would have.) I would be pleased to answer any or all questions concerning ACB or blindness in general for you, your users or their friends, relatives or acquaintances. If I don't know the answer, I usually know someone who does, and I love sending and receiving letters, so please feel free to direct any inquiry this way, no matter how off the wall it might be. (No matter what it is, I've heard it before, probably.) Thanks for your consideration, and ask your boss about those talkies. It might be just the push he finally needs to make the jump to cellular. ---Vernon Henley, Fido 147/1 Chair, Board of Publications American Council of the Blind 800-424-8666 (voice) Call after 5:30 pm Eastern time for a free, pre-recorded update on legislative, administrative and judicial action concerning the blind and handicapped. ------------------------------------------------------------ Fidonews Page 4 10 Feb 1986 Bruce A. White Fido 109/612 Confessions of a Fido Tyro Is WASH-A-RUG (109/483) a carpet laundry? That was my first thought, especially after I discovered that FIDO-FHLMC (109/456) really IS related to Freddie Mac. Just what is the story behind these electronic bulletin boards with cutesy illustrations of dogs on them? I was initiated to the world of Fido by an announcement in a publication of an organization I belong to. Having some experience as a subscriber to CompuServe, I was able to connect myself to the BBS listed in the announcement. After a few minutes I said to myself, this is very interesting, but what's it for? Also, knowing how the minutes add up to $$$s at CompuServe, I wondered how much this diversion was costing me. My state of perplexity wasn't aided by reading the sysop's editorial, in which HE was expressing some doubts about the usefulness of his new BBS. All of a sudden my monitor took on a life of its own, and I slowly realized that he was "chatting" with me. He reassured me that it was costing me nothing, but that made me even more leery. If it's free, then how can he afford the required time and equipment to do this? And though it seemed a bit dumb to be typing at each other, when we could have picked up the phone and talked much more quickly, I played along and enjoyed the conversation. I'm afraid now I'm hooked. A person who has always hated to use the phone, I now find myself dialing BBS numbers when I could be doing more constructive things. In the few days since I made my first Fido contact, I have graduated myself to Expert help-level status (even if I have to occasionally resort to "?"), and learned my way around several boards. I'd like to share some impressions and suggestions. I think the possibilities of sharing and communicating are what appeal most to me. I use my micro primarily for word- processing, and will probably never become a programmer. I admit that it is great to be able to download a file here and there, and obtain utilities or programs for free, but there are only so many utilities and programs one can use; beyond a certain point one approaches overkill or obsession. Because of the potential for communication, then, FidoNet and FidoNews are fascinating developments, and I hope more people will get modems and participate in BBS networking. Any use of technology that furthers interpersonal communication should be utilized to the fullest. But how can new participants in Fido networking best be obtained? As I groped my way around the boards, I got the impression that everyone else on the board was already a computer and Fidonews Page 5 10 Feb 1986 Fido expert; it was as though they had all gone through the same class together. Most Fido users seem to be into "heavy" technical stuff, and talk about hardware the same way guys used to talk about their cars and accessories. How does an outsider get into this seemingly closed group? I was able to see what Fido DOES to some extent, but I had no idea where it came from, why and when it was developed, and its guiding philosophy and goals (if any). On one board (The Trading Post) I was happy to find a "FIDO TUTORIAL" area, and a downloadable Fido User Manual. The sysop of this board obviously had the new user in mind when he designed it, and perhaps other boards should also take into consideration the fact that some users will know very little about what they are doing, and will need some coaching. I realize, though, that most sysops, being well advanced in computer and Fido usage (or else, I'm assuming, they wouldn't be sysops), don't want to clutter or slow up their boards by making them more "user friendly" for a Fido tyro. Consequently, perhaps there should be some boards that are set up EXPRESSLY for beginners. Such boards can have mostly ".TXT" files to be typed and downloaded, and a very non- threatening and supportive environment. Such boards could also have general information about Fido, or explain where such information can be obtained. Perhaps these boards could be operated by sysops who are not very far from being tyros themselves, and they could build up experience and expertise before tackling a more sophisticated BBS. I'd appreciate feedback (partly to prove that FidoNews really DOES get read). I think I'll go call another BBS--I wonder what the NASA Gas Net is all about? ------------------------------------------------------------ Fidonews Page 6 10 Feb 1986 Frank Mayhar 12/29/85 Stephen F. Austin State University FIDO 124/16 A Suggestion For a New File Transfer Protocol This article addresses the problems inherent in Ward Christensen's original XMODEM protocol, which are not entirely solved by any of the new protocols that have been introduced since. It then proposes a new protocol that would be a natural successor to the XMODEM protocol, and that may provide more effective long-term solutions to those problems. I. Introduction I have used Ward Christensen's XMODEM protocol for several years. In that time I have become aware of (actually, I have run head on into) several problems with it. These problems are mostly solved, to a greater or lesser degree, by many of the current new crop of protocols that have been introduced in the past few years. However, the methods by which they have been solved are less than might be desired, and introduce new problems, mostly of compatibility with existing file transfer methods. II. The Problems The problems I am referring to are (1) the total lack of a way to transfer file information (file name, length, creation date), (2) relatively poor data throughput, and (3) very poor performance of most software at high data rates (i.e. rates greater than about 1200 to 2400 baud). The first problem is self-evident in the protocol definition itself. Ward Christensen provided no way to transfer file information. The second problem has to do both with the theoretical efficiency of the protocol, and with the efficiency (or lack thereof) of the implementation. The theoretical efficiency of a protocol is determined by dividing the number of bits of actual data by the total number of bits transmitted. The obvious way to increase such efficiency, then, is to increase the amount of data transmitted relative to the amount of control information transmitted. The straight XMODEM protocol (using 128-byte blocks) ranges from about 95% efficient in the worst case, to about 96% efficient in the best case. (The best case occurs when the number of data bytes fits evenly into the transmitted blocks [the file length is evenly divisible by the block length, 128 in this case]. The worst case is when the last block transmitted contains only one actual data byte plus filler for the rest of the block.) The efficiency of the Fidonews Page 7 10 Feb 1986 same protocol using 1024-byte blocks ranges from 99% in the best case to 93% in the worst case. Efficiency is lowered in any case, of course, if errors occur. The average XMODEM efficiency is, therefore, around 96%. The average efficiency when using 1024-byte blocks is also around 96%. So increasing the block length is no solution to the theoretical efficiency problem. A better solution would be to use variable-length blocks (say varying between 128 and 1024 or 2048 bytes). This may also help solve another problem. The major problem with the actual effective data throughput of most XMODEM-type file transfers has to do with the efficiency of the software doing the transfer. In any transfer, the throughput of the transfer is controlled by the speed of the least efficient side of the transfer. Usually, at 300 or 1200 (or even 2400) baud, the inefficiency of most software is not noticeable. However, when the data rate is increased, the inefficiency of most of the software make the effective throughput stay around 1200 or 2400 baud, at best. (There are notable exceptions to this, particularly Greg Gilley's TERM terminal emulator program for the TI Pro, which is the absolute best I've seen at this. There may be others that I'm not aware of.) Although the best solution to this problem would be to optimize the efficiency of the software, this may not be feasible in all cases. Longer or variable block lengths, which increase the efficiency of the protocol and make the software spend more time actually transmitting blocks rather than processing, would undoubtedly help, even if it wouldn't completely solve the problem. In addition, there is a problem that stems from the attempts by a very large number of programmers to solve the problems outlined above. This can be summed up in the statement that none of the current file transfer protocols provide any convenient way for the receiving and trans- mitting programs to reconcile what extensions to the XMODEM protocol will be used in the current transfer. (These extensions include CRC error checking [rather than the checksum method used in the original XMODEM], and larger data packets [as in the relatively new YMODEM protocol, which provides 1024-byte data packets to increase through- put].) A compatibility problem also exists between different XMODEM-based protocols, such as Telink, MODEM7, and YMODEM. The current methods to accomplish some reconciliation between receiver and sender range in most new XMODEM-based protocols from nonexistent to the "C-instead-of-a-NAK" method for establishing CRC error checking, and different characters (instead of SOH) as packet prefixes in protocols that use a "packet zero" and non-128-byte-packets (see the descriptions below of the Telink and YMODEM protocols). Different implementations use different features, and future implementations may use still different features. There is really no way, currently, to accomplish this reconciliation, in any existing protocol. Fidonews Page 8 10 Feb 1986 There is another problem with most XMODEM-based protocols, having to do with CRC error checking. In most implemen- tations, a "C" is sent by the receiver instead of the first NAK, to signal CRC mode. If the transmitter hasn't responded by the third "C", the receiver switches to checksum mode, and sends a NAK. The transmitter presumably responds to this by sending the first data packet, and the transfer continues in checksum mode. The timeout for response to the "C" is three seconds. Thus, the start of the transfer may be delayed by as much as nine or more seconds, if the transmitter doesn't support CRC error checking. III. Some Existing Protocols There is currently a proliferation of new protocols, all more-or-less loosely based on Christensen's protocol. Most have features that are desirable. However, none of them have provided any really effective, long-term solution to the problems enumerated above, most of them are to some degree incompatible with Christensen's original protocol, and most, if not all, have added a level of complexity, to an originally simple protocol, that prevents them from really taking hold in the user community the way XMODEM has done. Some examples of these protocols include MODEM7 (originator unknown), YMODEM (originated by Chuck Forsberg), and Telink (originated by Tom Jennings). There are good and bad points about each of them. MODEM7 uses a very clumsy and error-prone method of trans- ferring the file name, although this does allow batch file transfers. YMODEM, used primarily on CP/M and UNIX systems, allows CRC error checking (using the "C-instead-of-a-NAK" method), 1024-byte data packets, and the transfer of file infor- mation (filename, length, and date) in a "packet zero", allowing batch file transfers. A problem exists in the YMODEM protocol, however, in the area of the 1024-byte packet length. According to the definition of the protocol, a 1024-byte packet is prefixed with a STX rather than a SOH, and the receiver must be able to handle any mix of 128- and 1024-byte packets. This use of STX as a data-packet prefix is inconsistent with the original simplicity of the XMODEM protocol. Telink uses the same clumsy method of transferring the file name that is used in MODEM7, which is ironic, as Telink transfers the file name again in a "packet zero", which also contains the file size and date, and is prefixed with a SYN rather than an SOH (see the description, above, of the YMODEM protocol). Telink also provides CRC error checking, using the "C-instead-of-a-NAK" method. Another protocol, which is not based on the XMODEM protocol, and which solves most of the problems in that protocol (at the expense of a lot of added complexity), is Fidonews Page 9 10 Feb 1986 the Kermit protocol. This protocol uses "command packets" to set various parameters between the receiver and the sender. This protocol is commonly used in university settings, between microcomputers and mainframes. The protocol is Unix-based. The primary reason that Kermit has not taken hold is because of that added complexity. Kermit can be difficult and tedious to implement, and the protocol has features that are unneeded by most microcomputer users, as well as some restrictions not present in the XMODEM protocol. IV. A New Protocol? Fine, you say. Problems exist. But is a new protocol required, when there is a huge (well, maybe not huge, but certainly large) proliferation of protocols. Wouldn't a new protocol just add to the existing mess? I say that a new protocol is needed. It should not try to be all things to all people, as some existing protocols do, and it should not compromise the essential simplicity of the original Christensen XMODEM protocol, except where absolutely necessary. It should, however, allow the use of the new features of XMODEM-based file transfer, such as CRC error checking and large packet lengths. It should attempt to allow file transfers with virtually any XMODEM-based file transfer protocol implementation, using the straight XMODEM protocol. It should also be as easily expandable as possible, in order to meet possible future needs. I propose a new protocol that would incorporate the following features: 1) NO IMPLEMENTATION SHOULD BE REQUIRED TO SUPPORT MORE THAN THE MINIMAL XMODEM FILE TRANSFER PROTOCOL, in terms of CRC error checking and packet lengths. This excepts the transfer of file information. 2) Transfer of file information, including filename, file size, and file date. The "packet zero" method? "Command packets", as in Kermit? 3) An easy way to let the receiver and transmitter agree on what features will be used in the current transfer. This is the major problem that I see with most of the current XMODEM-based protocols. This might be accomplished several ways. One way would be transmitter-driven, using a "packet zero" containing file info and several bytes devoted to what features are supported. Another method might use Kermit's solution to the problem, which involves the receiver and the transmitter exchanging some kind of packet (a "command packet") containing "feature-present" flags. The features used would be the exclusive-or of the "feature-present" flags. The packets might contain other information, as well. Fidonews Page 10 10 Feb 1986 4) The capability to support CRC error checking, with- out requiring such support. (That is, it should allow CRC error checking, but it should not pro- hibit the checksum method.) 5) The capability of using longer or variable packet lengths to increase data throughput. (Variable-length packets would be easily implemented by adding a control word to each packet containing the length of the packet.) 6) Batch file transfers. This should be accomplished easily, if item 2 is successfully accomplished. 7) Full minimal XMODEM compatibility, as the default. This means no file information transfer, no CRC error checking, 128-byte packets, and no way for the receiver and transmitter to communicate what features will be used (this last is obvious). This might be accomplished using the "C-instead-of-a-NAK" method, using some other character than C. Read "C" as NAK. 8) The protocol should be receiver-driven, as much as possible. However, a method should exist to exploit the full capabilities of each end of the transfer. This requirement may be changed or removed, as it and item 3 may prove to be mutually exclusive. 9) Easy expandability. The protocol should include some method (such as reserved fields in command packets or in a "packet zero") for future expansion. The full definition of the protocol would include all the enhancements outlined above. As shown, the protocol would also allow subsets (including a subset consisting of the original XMODEM protocol), and would define a way to specify which set of enhancements would be used for each transfer. There are a number of methods of satisfying these require- ments. I can see none that exactly fit the spirit of the original XMODEM implementation and that completely eliminate all the problems mentioned in this document. However, it may not be possible to do both. I can see several possible solutions that do satisfy these require- ments, using features from several of the existing proto- cols, and some new features. V. Conclusion The problems mentioned in this document are real, and the great proliferation of file transfer protocols are not helping the matter. As I see it, some new protocol is needed that is a logical successor to XMODEM, that incor- Fidonews Page 11 10 Feb 1986 porates most of the most-used features of the current protocols, and that is as compatible as possible with existing protocols. I think that the the general outline above may provide such a protocol. I have not started implementing this protocol, primarily because I don't want to go to all that work and have it be completely ignored. I would like to see the people most directly affected contribute their opinions and expertise to the solution of the problems I've mentioned. This means you, the public BBS user. By no means am I saying that the protocol I've outlined is THE solution. It is merely a suggestion for one possible solution. However, I do believe that a solution is needed, and soon. Obviously no one protocol can be completely satisfactory to every person in every situation. But we can come up with a solution that solves most of the problems I've mentioned, and is also easy to use and implement. As I mentioned above, I would like to see a lot of people get involved. My hope is that we, the user community, can get together and design and implement a good new protocol, standardize it, and get it into common use. If we can, per- haps the computer industry, which has for the most part ignored us (although there have been a few notable excep- tions recently), will begin to view us a a real innovative and productive force in computing. Let me hear your opinions. I can be reached on the following BBS's: JimNet (Austin) RBBS at (512) 837-0953 -- This is the one I use most. The Warbler (Warble2 FIDO, Dallas area) at (214) 521-8689 Leave mail for Frank Mayhar at those BBS's, or send Fido- Mail to me at FIDO 124/16 (the Warble2 FIDO, above). My address: Frank Mayhar P.O. Box 14963 SFA Nacogdoches, TX 75962 ------------------------------------------------------------ Fidonews Page 12 10 Feb 1986 Don Daniels Sysop, Fido 107/211 OUTSIDE In Version 11q of FIDO, a new command was added called O(utside). Similar to the Sysop-only "0" command, this command is available to any level of user (as set by the Sysop) and causes FIDO to terminate without dropping the phone connection. A specific ERRORLEVEL is returned that can be tested in the batch file that initiated FIDO in order to determine further action. (If you have recently upgraded to 11q, you must delete your old MAINPRIV.BBS, enter FIDO as a Sysop, and issue a "3 O priv-level" command for the O)utside command to work properly at the access level(s) you wish.) Just what such further action may be implemented is totally of no concern to FIDO, as it is left to the individual Sysops. This brings up the questions, "Just what should this facility be used for on my system?" and "How do I make sure that only the right people are running it and that they are not gaining control of the whole machine?" Well, the answer to the second question may well be in the form of a new program called, appropriately enough, OUTSIDE, which allows you to place several levels of control on what is executed and by whom. OUTSIDE is kind of like a miniature FIDO that displays a welcome message (OUTSIDE.WEL) on the screen, validates the users (again) by checking their names and passwords against USER.BBS, and then displays a small menu of options for user selection. These include: L List the services available to this particular user X Execute a service R Return to FIDO (via the batch file) ? Display contents of a Help file (OUTSIDE.HLP) The Services that are available to users are specified in a Service Control File called OUTSIDE.SRV which is created off-line by the Sysop. It allows for an identification and description of each service, optional passwords, specifica- tion of which of four levels of security should be used, the method of Service initiation, and, for those entries for which it is necessary, a list of authorized users. Depending on the nature of the Services, several Services may be executed by the user before returning to FIDO. A log, OUTSIDE.LOG, is maintained which keeps track of all OUTSIDE users, the Services they use, and certain anomalies which may occur. OUTSIDE.ARC is available for downloading from: Fidonews Page 13 10 Feb 1986 D2-FIDO (107/210) 516-682-8525 evenings or weekends at 1200-300 bps DANIELS-FIDO (107/211) 516-367-9626 most any time of day at 2400-300 It is distributed under the "Shareware" concept. Further documentation is available within the package. Actually, there are many potential uses for this feature that has been provided by Tom Jennings. I am willing to serve as a clearing-house for propositions, problems, programs, and what-all related to the use of the O(utside) command and the Services provided thereunder. Address all messages and files to Don Daniels, Sysop, FIDO 107/211 ------------------------------------------------------------ Fidonews Page 14 10 Feb 1986 ============================================================ COLUMNS ============================================================ You Can dTUNE A Program But You Can't dTUNE a Fish by Ben Silverstein Some of you may be familiar with a bulletin board system called The Lost Dutchman's Gold Mine RCP/M. It is based in Phoenix, Arizona and is run by James A. Gronek. If the board isn't familiar, Jim's name should be to anyone who has more than a passing acquaintance with public domain software. Jim has written several original and updated many existing public domain programs, mostly in the realm of dBASE II applications. One that will ring a bell with most users is DBSHELL, the .CMD file that makes dBASE more user friendly. Some time ago, Jim wrote a utility for dBASE command files called dTUNE. This little gem allowed dBASE programmers to write their files with liberal comments, proper indentation, and all the other habits essential to good programming, and then "detune" it to a file that was the absolute bare-bones that dBASE needs to run, and no more. All commands are reduced to their minimum 4 character representations, comments and unneccessary blank lines, tabs, and spaces are deleted. This reduces the space needed on disk for the files, increases execution time by eliminating number of lines that dBASE must parse, and makes it harder for someone to follow the program listing. The source file is not changed; all changes are written to a new file and the original renamed to type .SRC. The original public domain version was written in the dBASE language itself and tokenized with one of the commercial RUN-TIME(c) clones. This didn't allow listing, but could be run by the user with no difficulty. Jim has now rewritten the program in TURBO Pascal and is offering the latest version as a commercial product. As a beta tester, I have had the oppurtunity to try out the new version over the last couple of months. Several new features have been added to dTUNE, and execution time is much improved thanks to the speed of Turbo. With the package, Jim has included a terminal installation program so that dTUNE may be customized to run on a number of different terminals. This part was created using the GINST portion of the Turbo Toolbox utility disk from Borland that installs an application program with the same routine used to install Turbo itself. When the program is invoked, you are presented with a well laid out menu showing the program choices and their current condition. Most are toggles, and pressing the appropriate key will turn them on or off. Several combinations of Fidonews Page 15 10 Feb 1986 functions and outputs are available. Some of the high points of dTUNE are that it: - Prints a nested and indented listing of your command file with lines connecting the IF/ENDIF, DO WHILE/ENDDO, and DO CASE/ENDCASE pairs. This makes debugging easier in that is is readily apparent if you have an open-ended function. - Alters the case of your command file. Text may be changed to upper or lower case as you wish, with delimited fields left untouched. - Produces a trimmed file as described above that will have a faster execution time. - Produces a nested and indented version of the trimmed file. Handy in case you lose the original file and must reconstruct it from the dTUNEd version. - Produces a cross-referenced listing of all memory variables. Two files are produced: a .PRN file containing line numbers, and a .XRF file with all variables listed alphabetically. - Allows a listing of any of the above files to be sent to the printer, saving the trouble of printing them manually later. A status window is updated during processing, allowing you to monitor the progress of dTUNE. This program works very quickly, and I have found no bugs in the times that I have used it. I have a small wish list, but that is always the case. dTUNE will run on any Z-80 based computer with a miminum 48K TPA. A smaller (40K) TPA version is available for those who need it. The public domain version (v3.1) of dTUNE can be found on many remote systems around the country, or on Jim's board at the number below. Check drive A2: for the CP/M version, and A9: for the MS-DOS edition. dTUNE 4.0 is in beta testing now and will be available soon. The price will be approximately $35.00 from Jim through his company, UCS, Inc. You may order by mail to the following address: Jim Gronek UCS, Inc. P.O. Box 23866 Phoenix, AZ 85063 The number for the Lost Dutchman's Gold Mine RCP/M system is: (602) 848-6708 24 hrs, 300/1200/2400 baud There is also a second system on line dedicated to ZCPR- Fidonews Page 16 10 Feb 1986 related items. Check the first system for details. ------------------------ You might not know that dTUNE is (C) UCS, Inc., but if you don't already know that dBASE II and RUN-TIME are (C) Ashton-Tate and that TURBO Pascal and Turbo Toolbox are (C) Borland International, don't expect me to tell you. Also, acknowledgements to REO Speedwagon for the inspiration for the title of this piece. ------------------------------------------------------------ Fidonews Page 17 10 Feb 1986 Editor's note: We've recently received a set of back issues to the European counterpart of FidoNews. We'll be running articles from them for the next several issues. I apologize to our European readers for printing what is to you old news, but it's new to many of us here in the Colonies. Notes from Abroad Hello, Good-Evening, and Welcome. Unlike my continental counterparts I am not multilingual, I have trouble with English! I will apologize now if you cannot translate this! There is so much public domain software around that a new medium for distribution must be found. I have a DC-600 tape backup (25 Meg) and I am willing to let any Fido sysop who has a DC-600 tape backup have a copy of my tapes. This makes much more sense than sending hundreds of floppy disks through the post. The tape is not finished yet and I am still looking for more software, please send me any new public domain software or anything that is not listed in my catalog. I am currently negotiating with several UK hardware houses to supply me with various types of tape streamers, cassette backups, and removable hard disks. I suggest that any Fido sysop who has not yet got a tape backup that they contact their local hardware houses and put this idea to them: There are approximately 500 Fido systems throughout the world, each with the same problem as me; lots of public domain software, (I have 500 disks, 60 Meg) and no fixed standard for distribution except the floppy disk. If the same tape streamers were supplied to all Fido's (DC-600, or DC1000) that in itself should establish that particular unit as the de-facto standard for exchange of an ever increasing supply of public domain software. If we can work together on this one I think we would all be better off. Just think what a bonus it would be to various tape manufacturers. They could tell potential customers that if they bought their backup system that they could ask the various user groups and bulletin boards for a copy of their public domain software library on tape!! If anyone has tried this approach, or has any ideas or suggestions please let me know. I think it would be a good idea to conduct a census on all Fido nodes to see what sort of backup we use. It may be that we have a standard already without knowing it. Is anyone willing to conduct the aforementioned census? Please send all ideas to me, Fido 4403. ------------------------------------------------------------ Fidonews Page 18 10 Feb 1986 ============================================================ WANTED ============================================================ Gary W. Aili Fido 104/3 WANTED! S.I.G administrators for Financial TeleShare. Financial TeleShare is the first exclusively dedicated on- line financial information and education forum! Our members receive a variety of benefits including: in- depth education, counseling, conferencing, practical assistance, personal and business planning, extensive market data & services, monitored product performance, free personal message network, U.S. and Internat'l telex, 50 state local call access, and more. HELP! We need FINANCIAL S.I.G. ADMINISTRATORS with professional expertize and experience in financially oriented subject fields including: planning, investments, banking, insurance, entrepeneurship, collectibles, business services and others. S.I.G. formation and management experience preferred. MUST enjoy on-line WORK! As a S.I.G. administrator, you and/or your business can benefit from our NATIONAL membership. To respond, send a message via FidoMail to Gary Aili (Fido 144/3) describing your interest, experience and contact information. Financial TeleShare is Fido 144/3. We may not yet be on your node list, but your can still reach us through 144/0. ------------------------------------------------------------ Fidonews Page 19 10 Feb 1986 ============================================================ FOR SALE ============================================================ ENTERTAINMENT SOFTWARE FOR YOUR PC! SUPERDOTS! KALAH! Professional quality games include PASCAL source! From the author of KALAH Version 1.6, SuperDots, a variation of the popular pencil/paper DOTS game, has MAGIC and HIDDEN DOT options. KALAH 1.7 is an African strategy game requiring skill to manipulate pegs around a playing board. Both games use the ANSI Escape sequences provided with the ANSI.SYS device driver for the IBM-PC, or built into the firmware on the DEC Rainbow. Only $19.95 each or $39.95 for both exciting games! Please specify version and disk format. These games have been written in standard TURBO-PASCAL and run on the IBM-PC, DEC Rainbow 100 (MSDOS and CPM), CPM/80, CPM/86, and PDP-11. Other disk formats are available, but minor customization may be required. BSS Software P.O. Box 3827 Cherry Hill, NJ 08034 For every order placed, a donation will be made to the Fido coordinators! Also, if you have a previous version of KALAH and send me a donation, a portion of that donation will also be sent to the coordinators. When you place an order, BE CERTAIN TO MENTION WHERE YOU SAW THE AD since it also appears in PC Magazine and Digital Review. Questions and comments can be sent to: Brian Sietz at Fido 107/17 (609) 429-6630 300/1200/2400 baud ------------------------------------------------------------ Fidonews Page 20 10 Feb 1986 ============================================================ NOTICES ============================================================ The Interrupt Stack 22 Feb 1986 Submissions deadline for the CROBOTS competition. Ask Andy Foray at 107/7 for details. 1 Mar 1986 The Next Occasional MetroNet Sysop Meeting, to be held at Matt Kanter's apartment. Check with Matt at 107/3 for details. 1 Mar 1986 European mail hour shifts to 0230-0330 GMT. Summer time will no longer be observed. 11 Apr 1986 Halley's Comet reaches perigee. 19 May 1986 Steve Lemke's next birthday. 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to Fido 1/1. ------------------------------------------------------------ Fidonews Page 21 10 Feb 1986